1. Field of the Invention
The invention relates generally to object-oriented technology. More specifically, the invention relates to collaboration between components in a distributed application.
2. Background Art
Modern enterprise applications are typically implemented as multi-tier systems. Multi-tier systems serve the end-user through a chain of client/server pairs. Enterprise systems are typically implemented in a number of components, where each component may contain multiple object instances at runtime. Each component interacts with other system components at runtime to provide a set of functions to the system.
FIG. 1 shows an example of a four-tiered system that includes a user interface tier 2, a web server tier 4, an application server tier 6, and a data tier 8. The user interface tier 2 is the layer of interaction and typically includes a form-like graphical user interface (GUI) displayed by a display component, typically a web browser 10. The web server tier 4 includes web components 12 hosted on a web server 14. The web components 12 generate the content displayed by the web browser 10. The application server tier 6 includes application components 16 hosted on an application server 18. The application components 16 model the business rules, typically through interaction with application data. The data tier 8 includes a persistent data store, typically a database management system (DBMS) 20 and a database 22.
The web browser 10 and the web server 14 form a client/server pair. The web server 14 and the application server 18 form another client/server pair. The application server 18 and DBMS 20 form yet another client/server pair. A web component 12 and an application component 16 are in a client/server relationship when the web component 12 (client) uses services of the application component 16 (server) to provide functions to the system. In order for the client and server to collaborate, there must be a contract, or interface definition, between the client and server that specifies the server methods that can be invoked by the client. When the client and server are in different address spaces, the client uses some form of remote procedure call (RPC) to invoke the server methods. Typically, this involves the client calling into a local stub, which forwards the call to the server.
The granularity of an object is a measure of the size of the object and the number of the interactions the object makes with other objects. Large-grained objects have few interactions with other objects, while fine-grained objects have many interactions with other objects. Object-oriented, client/server programmers often develop server programs that embed large-grained and fine-grained object models. One of the consequences of fine-grained behavior is that the client program makes excessive remote method calls to the fine-grained object in the server program in order to access and update the attributes of the object. Remote method calls are expensive in terms of computer processor usage, input/output access, and overall time usage. For each remote method call, data may have to be marshaled and later un-marshaled, authentication may have to be performed before the client can use services provided by the server, packets may need to be routed through switches, and so forth. Thus, numerous remote method calls can have a huge impact on the performance and scalability of the application. For optimal distribution performance, the number of client/server roundtrips must be minimized.
The process of developing and deploying components in a distributed environment, such as that illustrated in FIG. 1, is often iterative and incremental. It is not unusual to alter the different components of the distributed system a few times before the components reach a stable state. These modifications may include changing the interface and behavior of the objects in the components. Also, due to lack of distributed debuggers, it is common to inject code into the distributed application for the purpose of debugging the application.
Difficulties arise when modifications are made to the distributed application while the application is running. For example, if the interface or behavior of a remote (server) object is changed, all the parts of the distributed application have to be halted in order to re-deploy the modified remote object and its respective stubs on all the clients. Re-deployment resets the running state of the distributed application, requiring the application to be restarted. This makes deployment of distributed components extremely dependent on each other. Also, every time a new debug statement is injected into the distributed system, the entire application has to be re-deployed, making the edit, compile, and deploy cycle tedious.
At this point, there is no known work that allows distributed applications to run seamlessly after the interface between the components of the application has been modified. Most object request brokers (ORBs) and application servers support hot deployment, which allows modifications made to distributed applications to take effect without bringing the servers down. However, these deployment mechanisms typically reset the running state of the applications, resulting in the client stubs going “stale.”